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In the Specification : 

Please replace the paragraph on Page 14, lines 6-13, with the following marked-up replacement 
paragraph: 

- Alternatively, the satellite TV operator site may host a merchant's site providing the 
merchant site services 1 50 locally within the satellite TV operator site 120. Therefore, when the 
consumer interacts with his television or set-top box 110 and provides input over the telephone 
line 1 15 to the interaction interface 130, the interaction information is directed to the local 
merchant's site 150 (rather than the Internet 160), where the local site responds to the consumer 
1 10 via transmission 125, 105 through the satellite 100. Or, merchants may have their own 
information systems in their own locations (not shown in Fig. 1), connected to the satellite system 
120, in which case the interaction information is directed in this same manner. — 



Please replace the paragraph on Page 15, lines 5 - 23, with the following marked-up replacement 
paragraph: 

- Interactive retail merchandising and purchasing can be conducted in the satellite TV 
A system of Fig. 1 or the cable TV system of Fig. 2, or in the broadcast television environment. 
\ N These different environments will be referred to hereinafter as "interactive television systems" or 
"interactive television environments" for ease of reference. A merchant can display an offer to a 
TV viewer by sending data through the interactive television system. The consumer can then 
accept an offer and make a payment using the return signal path. The payment for an item may be 
made in a number of ways. The payment may be made by entering credit card information into a 
form that is transmitted from the merchant to the consumer. Or, one of a number of specialized 
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payment protocols may be used to exchange payment-related messages for the purchase. 
Examples of these payment protocols include: (i) Secure Electronic Transactions, or SET™, 
defined by MasterCard®, Visa®, and other companies; (ii) the protocol defined by the X9.59 
standard, titled "ANSI X9.59-199x for the Financial Services Industry: Account-Based Secure 
Payment Objects", of the American National Standards Institute; or (iii) a 4-Party Internet 
Credit/Debit Protocol as disclosed in U. S. Patent 6,327.578 (serial number 

09/221,869, filed 12/29/1998). These payment protocols are augmented according to the present 
invention to include TV context information related to a consumer's TV-based purchase, as will 
be discussed in more detail below. ("SEP' is a trademark of SET Secure Electronic Transaction 
LLC, "MasterCard" is a registered trademark of MasterCard International Incorporated, and 
"Visa" is a registered trademark of Visa International Service Association.) — 

Please replace the paragraph on Page 23, lines 3-7, with the following marked-up replacement 
paragraph: 

- An important aspect of the present invention is the fact that the merchant cannot 
tamper with the any of the contents of the authorization token, specifically including the TV 
context information. Since the token is digitally signed by the issuing bank, any modification 
thereof will be detected by the acquiring bank. The acquiring bank will then deny payment to the 
merchant, and prevent allocation of any revenues to TV originators. - 



Please replace the paragraph on Page 23, lines 8-19, with the following marked-up replacement 
paragraph: 
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- Fig. 4 illustrates the transaction flows with which a second preferred embodiment of 
the present invention may be implemented when using a 3-Party Credit/Debit Protocol (such as 
SET or X9.59). When using a 3-Party system, the purchase request is forwarded from the 
consumer to the merchant, and the merchant then forwards this information to the acquiring 



bank, which forwards it to the issuing bank. The consumer does not interact with the issuing 
bank in a 3-Party system (as in contrast to the approach described above for the 4-Party system); 
rather, the acquiring bank contacts the issuing bank (e.g. to determine whether the consumer's 
account is still active, and whether the account can accept new charges or debits, etc.) in this 
system. The acquiring and issuing functions in a 3-Party system may be performed by different 
card companies or banks, or they may be performed by a single card company or bank (including 
the scenario where different entities within the single card company or bank perform the acquiring 
and issuing functions). 3-Party systems are commonly used by credit card operations such as 
MasterCard and Visa. — 




Please replace the paragraph that begins on Page 23, line 20 and carries over to Page 24, line 25, 
with the following marked-up replacement paragraph: 

— The transaction flows of Fig. 4 are similar to those of Fig. 3, and begin with the 
consumer initiating the process by creating a "buy" indication 400 using a browser (as described 
in Fig. 3). The TV context information is then gathered. (As described above, static portions of 
the TV context information which are unrelated to the point in time at which the TV commerce 
transaction was initiated may alternatively be gathered at a later point in the process.) The "buy" 
indication 400 is sent to, and received by, the merchant and is processed using techniques which 
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do not form part of the present invention. The merchant responds 405 to the consumer with a 
wallet initiation message which is digitally signed by the merchant and which includes the 
merchant's digital certificate. The consumer logs on to the wallet program (as described with 
reference to Fig. 3). The consumer's wallet program sends 410 the information from message 
405, the gathered TV context information, and the consumer's identification and other 
information provided by the wallet program to the merchant. Preferably, this information is 
signed by the consumer before transmission, as described above with reference to message 310. 
This message 410 is a purchase request from the consumer. Following receipt of message 410, 
the merchant sends an authorization request 415a to the acquiring bank, which is then forwarded 
415b to the issuing bank. Messages 415a and 415b constitute a request for the issuing bank to 
charge the consumer's account for the amount indicated, and to pay the merchant indicated in the 
message. The issuing bank verifies the message contents, as described above with reference to 
the issuing bank functions with refer e nce to in Fig. 3 (e.g. determining whether the consumer's 
account is valid and whether it has sufficient funds or credit for this transaction), and begins 
processing the information. The issuing bank, upon a successful verification, sends 420a an 
authorization response to the acquiring bank, which then forwards 420b this message to the 
merchant. The merchant, in turn, sends 430 a purchase response to the consumer. The merchant 
also sends 435 a capture request to the acquiring bank, after which the acquiring bank sends a 
message 440 to the issuing bank, indicating that the consumer's account is to be charged for the 
purchase. The TV context information included in the capture res pons e request may then be 
processed by the acquiring bank (as described for Fig. 3 above). A capture response is sent 445 
from the acquiring bank to the merchant, as discussed with reference to message 335 of Fig. 3. ~ 
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Please replace the paragraph that begins on Page 25, line 1 1 and carries over to Page 26, line 7, 
with the following marked-up replacement paragraph; 

- Fig. 5 illustrates the transaction flows with which allocation and distribution of funds 
may be made, according to the preferred embodiments of the present invention. (While Fig. 5 
specifically depicts the flows in a 4-Party system, it will be obvious to one of skill in the art how 
the analogous 3-Party flows may be substituted. In particular, if the acquiring bank and issuing 
bank are replaced by a single entity within a single bank, then flows 505 and 510 may be 
omitted.) The capture request (which represents the same message shown in Fig. 3 at 325, or 
equivalently, message 4W 435 in Fig. 4) is sent 500 from the merchant to the acquiring bank. 
The acquiring bank forwards 505 the charge (indicating, inter alia, the amount of the purchase) to 
the issuing bank for payment. The issuing bank processes the information, deducts the funds from 
the consumer's debit card or charges the amount to the consumer's credit card, and transfers 510 
the appropriate funds to the acquiring bank. The issuing bank typically charges a percentage of 
the purchase amount for its services. This amount (e.g. from 2 to 8 percent) is deducted by the 
issuing bank from the total amount before the funds are transferred to the acquiring bank. The 
acquiring bank typically also collects a fee for its services (again, often from 2 to 8 percent) which 
is deducted from the transferred funds. The acquiring bank preferably also processes the TV 
context information (see Fig. 6) at this point, where the context information was received as part 
of the capture request 500 according to the present invention, and allocates part of the revenue 
stream to the TV originators. This fund allocation may occur either directly to the TV 
originator's bank 515 by electronic deposit, it may be made by check, or it may be made by some 
other pre-arranged mechanism. When the TV context information processing is completed, the 
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remaining funds are transferred to the merchant's bank account at the acquiring bank (or perhaps 
at another bank where the merchant maintains an account). - 



Please replace the paragraph that begins on Page 26, line 8 and carries over to Page 27, line 5, 
with the following marked-up replacement paragraph: 

— Fig. 6 is a flowchart illustrating the logic involved with allocation and distribution of 
r/\ collected funds according to the preferred embodiments of the present invention. The acquiring 
bank at Block 600 receives the transferred funds from the issuing bank (see flow 5 1 0 of Fig. 5). 
(In the 3 -Party system scenario where a single entity within a single card company or bank 
performs both the acquiring and issuing functions, Block 600 represents the card company or 
bank receiving the funds directly from the consume r's account .) The payment message is then 
checked at Block 605 to determine if TV context information is present. If Block 605 has a 
negative result, then processing continues to Block 610 where the funds are processed according 
to the prior art (including deduction of the acquiring bank's or card company's fee, and 
distribution of the remaining funds to the merchant's account). If Block 605 has a positive 
response, then processing continues to Block 615 where the TV context information is extracted 
from the payment message. At Block 620, funds are allocated to the TV originator as indicated 
by the TV context information. The maimer in which the amount of funds to allocate to a 
particular originator is determined may vary from one implementation of the present invention to 
another, without deviating from the inventive concepts disclosed herein. The information needed 
for the allocation (such as a percentage rate to apply) may be present in the transmitted messages. 
Or, this information may be determined by consulting a stored repository of rates; by coding the 
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information into a configuration file locally accessible to the code processing the allocation; by 
coding the information directly into the code processing the allocation; etc. (It will be obvious 
that the latter technique is preferably used only when allocation rates are unlikely to change 
frequently.) Typically, the rates to be used will have been agreed upon by contract terms, and 
may vary from one TV originator to another. — 
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